Relational data bases and other file systems may use Structured Query Language (“SQL”) to phrase queries to access the relational data base. For example, in a relational data base, data items can be organized into rows and columns with indexes for each row and column. An SQL query can indicate a search for data items that satisfy a single criteria or a combination of search criteria, such as matching a specified index for a row AND matching another specified index for a column. For example, rows of a table can represent records and columns of the table can represent fields or attributes of the records. Also, data in one table identified by the row and column indexes of the one table can be used to index into another table to collect additional information.
The following is an example of a SQL query: SELECT TOP 1 name_FROM sysobjects WHERE xtype=‘U’. “WHERE” is a query operand and “name” is data. This SQL query retrieves the first value found in the column “name” from the table “sysobjects” where the value of the column “xtype” is equal to “U”. The following are examples of known query operands used with data or parameter values to search an SQL data base: AND, NAND, OR, NOR, EXCLUSIVE OR, WHERE, UNION and LIKE. A SQL query can also include characters and symbols such as the following used with data or parameter values to search an SQL data base: =, >, <, #, ″, @, /* and */.
Some web applications are vulnerable to an attack known as SQL injection. In this type of attack, hackers inject SQL queries into parameter/data values of requests made to the web application such as parameter values for GET and POST requests. Vulnerable applications may not detect the SQL query in the parameter values included in the request, may incorporate the parameter values as a SQL query and send the SQL query to a SQL database for processing. The resultant SQL query can be malicious and damage the database or cause an unwarranted search into a SQL database and post sensitive data for the hacker.
It is known to maintain a list of common types of SQL queries that may be injected into parameter value fields of a request to a web application, and compare all parameter values in the request against the list to determine if they match. The following is an example of a malicious type of SQL query represented in the list (in regex format): SELECT.* FROM.* (WHERE)?, EXEC xp.* or 1=1. If a parameter value in a request to the application matches an entry in the list, then the parameter value is presumed to be malicious and discarded. One problem with such a scanning system is the large number of entries in the list, and the time required to compare each new query to the entries in the list. Another problem is that the list may inadvertently omit one or more malicious types of SQL queries.
An object of the present invention is to detect attempts at SQL injection.
Another object of the present invention is to simplify the detection of SQL injection and minimize false positives and false negatives/evasions.